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mance  Evaluation  and  Requirements  Simulation)  now  exists  in  a  version 

< 

which  contains  extensive  revisions  in  the  areas  of  radar  surveillance 
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and  radar  tracking.  To  upgrade  the  capability  of  the  SPEARS  simula¬ 
tion  of  shipboard  radar  surveillance,  a  detailed  radar-surveillance 
model  designated  SLIRSEM  (Surveillance  Radar  Systems  Evaluation  Model) 
has  been  modified  and  incorporated  into  SPEARS.  In  addition,  a  simple 
tracking  algorithm  has  also  been  added  to  replace  the  implicit  assump¬ 
tion  that  a  target  track  is  established  instantaneously  upon  initial 
detection  and  then  carried  automatically  until  the  target  either 
leaves  the  radar's  coverage  volume  or  terminates  its  flight.  Due  to 
time  and  financial  constraints,  this  version  of  SPEARS  has  undergone 
only  limited  testing  at  present.  —  " 


The  attached  pages  document  the  radar  surveillance/radar  track¬ 
ing  variant  of  SPEARS.  They  are  intended  to  be  integrated  into  the 
existing  SPEARS  handbook,  ("SPEARS,  An  AAW  Performance  Simulation," 
D.J.  Kaplan  et  al . ,  NRL  Report  7958,  June  9,  1976).  Pages  with  page 
numbers  ending  in  a  numeral  are  meant  to  replace  those  with  the  iden¬ 
tical  numbers  in  the  SPEARS  handbook.  Pages  with  page  numbers  ending 
in  a  letter  are  intended  to  follow  those  with  the  identical  numerical 
portion  in  the  handbook. 
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1.6  Radar  Surveillance/Radar  Tracking  Variant 
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A  version  of  SPEARS  is  now  available  which  contains  extensive  re¬ 
visions  in  the  areas  of  radar  surveillance  and  radar  tracking.  To  up¬ 
grade  the  capability  of  the  simulation  of  shipboard  radar  surveillance, 
a  detailed  radar-surveillance  model  called  SURSEM*  (Surveillance  Radar 
Systems  Evaluation  Model)  has  been  modified  and  incorporated  into  SPEARS. 
For  each  active  surveillance  radar  the  SURSEM  submodel  produces  radar 
single-scan  probability-of-detection  values  as  a  function  of  target 
range  and  orientation.  Actual  detections  are  then  determined  by  Monte 
Carlo  sampling.  SURSEM  operates  within  an  expanded  SPEARS  environment 
which  may  include  wind,  rain,  and  multipath  propagation.  A  surveillance 
radar  is  characterized  by  its  radar  scan  modes.  A  radar  scan  mode  is  a 
means  of  defining  radar  operating  characteristics  for  the  illumination 
of  a  specific  geometrical  region.  Typical  radar  scan  modes  include  ele¬ 
vation  beams,  long-range  search,  high-angle  low-energy  search,  burn- 
through,  and  horizon  scan.  For  a  given  radar  scan  mode  of  a  surveil¬ 
lance  radar  scan  the  signal  (target),  noise,  jamming,  and  clutter  ener¬ 
gies  are  calculated  for  each  active  target.  The  probability  that  the 
radar  scan  mode  will  detect  a  target  is  then  computed  using  the  user- 
designated  Marcum-Swerling  cross-section  model  for  that  target. 

A  simple  tracking  algorithm  has  also  been  incorporated  into  SPEARS. 
The  original  version  of  SPEARS  assumes  implicitly  that  a  target  track 
is  established  instantaneously  upon  the  initial  detection  of  the  target. 
The  track  is  carried  automatically  until  the  target  either  leaves  the 
coverage  volume  of  the  radar  or  terminates  its  flight.  In  this  revised 
version,  a  target  track  is  established  only  after  three  detections  by 
any  radars  on  a  single  ship  within  a  specified  time  interval.  Target 
tracks  are  cataloged  and  carried  by  ship  or  defense  unit  rather  than  by 
an  individual  radar.  The  time  window  for  track  establishment  is  an  ad¬ 
ditional  characteristic  of  ship  type.  A  target  track  is  updated  (with¬ 
out  error)  with  a  detection  by  any  radar  on  any  ship  or  defense  unit  in 
communication  with  the  ship  carrying  the  track.  A  target  track  is 
dropped  by  a  particular  ship  whenever  a  30-second  interval  has  elapsed 
during  which  no  updates  from  any  communicating  ships  were  made. 


*D.J.  Kaplan,  A.  Grindlay,  and  L.  Davis,  "Surveillance  Radar  Systems 
Evaluation  Model  (SURSEM)  Handbook,"  NRL  Report  8037,  Jan.  14,  1977. 
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The  noise  energy  for  2D  radars  is 

Ns  =  C2  +  C3  J2  (j  e  G)  tJjGH^j-0GV(ej)Rj2] 
and  for  3D  radars  is 

Ns  •  C2  +  C3  L  «  ‘  G>  tJjGH<‘j-s>GV(6re>f]' 
The  signal-to-noise  energy  ratio  is: 


*  *  ★ 
ps  =  VV 


Then  the  probability  of  detection  P  is  calculated  as  a  function  of 

★  L) 

ps,  the  false  alarm  probability  of  the  radar,  and  the  number  of  pulses 
integrated  for  a  detection  decision.  This  is  under  the  assumption  of  a 
Marcum  and  Swerling  type-3  target. 

2.3A  Radar  Survei 1 1 ance/Radar  Tracking  Variant 

In  the  revised  version  of  SPEARS  called  the  radar  surveillance/ 
radar  tracking  variant,  the  shipboard-radar-surveillance  function  is 
performed  by  the  incorporated  submodel  SURSEM  (Surveillance  Radar  Sys¬ 
tems  Evaluation  Model).  Since  SURSEM  has  been  documented  in  detail,* 
an  abbreviated  description  of  the  detection  process  will  be  given  here. 
A  surveillance  radar  is  characterized  by  its  radar  scan  modes,  which 
define  the  radar's  operating  characteristics  for  the  illumination  of 
specific  geometrical  regions.  For  each  active  scan  mode  of  a  surveil¬ 
lance  radar,  a  single-scan  probabil ity-of-detection  of  each  active  tar¬ 
get  is  calculated  as  a  function  of  the  target's  position  and  environ¬ 
ment.  The  process  takes  into  account  the  target  aspect  angle,  target 
fluctuations,  multipath  propagation,  rain  and  sea  clutter,  rain  atten¬ 
uation,  and  jamming. 


*D.J.  Kaplan,  A.  Grindlay,  and  L.  Davis,  "Surveillance  Radar  Systems 
Evaluation  Model  (SURSEM)  Handbook,"  NRL  Report  8037,  Jan.  14,  1977. 


2-11 


The  free-space  returning  signal  power  at  beam  maximum  from  a 
given  target  is  calculated  according  to 

_  Pt  G2  x2  «(*)  Lr  Lt  Lm 


r  (4.)*  R4 

where  P  is  the  peak  power,  G  is  the  one-way  antenna  gain,  x  is  the 
radar  wavelength,  CT( 4»)  is  the  computed  target  cross  section  as  a  func¬ 
tion  of  aspect  angle,  R  is  the  target  range,  and  Lp,  Lt,  and  l_m  are 
the  receiver,  transmitter,  and  mode-dependent  losses  respectively.  The 
received  signal  energy  is 


S  =  P 


T[f(e)r  F4  Ar  [min(BIFTc,  1)  ], 


where  t  is  the  pulse  length,  f(e)  is  the  one-way  beam-pattern  factor 
as  a  function  of  the  angular  displacement  of  the  target  from  beam  cen¬ 
ter,  F  is  the  calculated  multipath-pattern-propagation  factor,  Ap  is 
the  computed  two-way  rain  attenuation  factor,  and  BIF  Tc  is  the  radar's 
IF  bandwidth  multiplied  by  its  compressed  pulse  length. 

The  total  noise  energy  includes  thermal  noise,  jamming  energy,  sea 
clutter,  and  rain  backscatter.  The  thermal  noise  energy  is 


NT  ■  FnkT0 


where  F^  is  the  receiver  noise  figure,  k  is  Boltzmann's  constant,  and 
Tg  is  the  system  temperature.  The  free-space  jamming  energy  contribu¬ 
ted  by  each  jamming  target  is 

F  .  GrLrLmSj  fHV*2 

M  ‘  (4„y 


where  iS  the  one-way  antenna  gain,  Lr  is  the  receiving  antenna  loss, 
Lm  is  the  mode-dependent  loss,  Sj  is  the  jamming  power  density,  fHy  is 


the  beam  pattern  factor,  x  is  the  radar  wavelength,  and  R  is  the  slant 
range  from  the  radar  to  the  target.  The  jamming  energy  contributed  by 
each  jamming  target  is  then  modified  by  the  appropriate  one-way  pattern 
propagation  factor  to  account  for  the  effects  of  multipath  propagation, 
so  that 


E 


J 
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and  the  total  jamming  energy  is 


1 

where  Nj  is  the  number  of  jamming  targets.  To  determine  the  contri¬ 
bution  of  sea-clutter  to  the  total  noise  energy,  the  normalized  mean 
backscatter  aQ  from  the  sea  surface  is  calculated  as  a  function  of 
radar  frequency,  wind  velocity  and  the  height  to  which  it  corresponds, 
target  angle  of  incidence,  and  polarization  orientation.  The  total 
sea-clutter  energy  is  considered  to  be  the  energy  that  is  reflected 
from  an  annulus  of  width  AR,  defined  by 

ar  =  — sec  (<d) 


where  r  is  the  pulse  length  and  o>  is  the  grazing  angle.  Then,  the  total 
sea-clutter  energy  E,  which  can  be  derived  by  a  lengthy  calculation,  is 
reduced  by  the  radar's  sea-clutter  improvement  factor  Ic: 


Rain  is  modeled  by  a  large  number  of  independent  scatterers,  each  of 
cross  section  and  located  within  the  radar  resolution  cell.  If 
the  raindrop  diameter  is  assumed  small  in  comparison  to  the  radar's 
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wavelength,  can  be  expressed  in  terms  of  drop  diameter  or  ulti¬ 
mately  rainfall  rate,  so  that  the  total  rain  cross  section  in  the 
resolution  cell  is 

°R  =  6.706  x  10'6  TC9B*BR2  r1,6  *'4, 


where  *  is  the  compressed  length,  6  and  ♦  are  the  horizontal  and 

C  D  D 

vertical  3-dB  beamwidths  respectively,  R  is  the  target  range,  r  is  the 
rainfall  rate,  and  x  is  the  radar  wavelength.  The  rain  backscatter 
energy  is  computed  according  to 


E  .  6VrV 
R 


where  I£  is  the  radar  rain-clutter  improvement  factor.  The  total  noise 
energy  is 


N  =  ("t  *  ETJAor  *  Ec\  *  Vr,max(Blf  11  • 

where  A  and  A  are  the  one-way  and  two-way  rain  attentuation  factors 
or  r 

respectively,  and  the  adjustment  factor  max(BjpT,  1)  allows  for  in¬ 
creased  noise  due  to  an  unmatched  IF  bandwidth.  The  single-scan  proba¬ 
bility  of  detection  is  then  calculated  according  to  the  specified 
Marcum-Swerling  target  cross-section  model  as  a  function  of  the  signal- 
energy-to-noise-energy  ratio  S/N,  the  number  of  pulses  integrated,  and 
the  probability  of  false  alarm. 
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2.4  Characterization  of  a  Defensive  Weapon  System 


The  specification  of  the  battle  scenario  used  to  initiate  the  sim¬ 
ulation  includes  a  characterization  of  each  defensive  and  offensive  unit. 
The  description  of  a  defense  unit  includes  a  description  of  its  weapon 
systems,  each  of  which  is  modeled  as  consisting  of  a  missile,  a  launcher, 
a  missile  magazine,  and  an  associated  missile  guidance  system.  Although 
a  unique  association  exists  between  launcher  and  missile  magazine,  a  given 
missile  guidance  system  may  service  a  number  of  inidvidual  launchers.  To 
simplify  bookkeeping  within  the  simulation,  a  weapon  component  is  classi¬ 
fied  by  function  (launcher,  missile,  or  guidance)  and  by  function  type. 

For  example,  if  seven  launcher  types  are  defined  for  the  task  force  for 
a  particular  game  play,  the  launcher  configuration  of  any  defense  unit  is 
specified  simply  by  stating  the  type  (from  among  the  seven)  and  position 
of  each  launcher  carried  by  the  unit. 

The  following  four  sections  are  a  description  of  the  properties 
which  characterize  each  of  the  four  parts  of  a  weapon  system  in  this  model. 
(A  more  complete  discussion  of  these  is  found  in  Ref.  2.) 


2.4.1  The  Surface-To-Air-Missile 

A  SAM  missile  type  is  described  by  the  following  missile  character¬ 
istics: 

•  minimum  and  maximum  intercept  ranges, 

•  performance  envelope, 

•  time-of-f light  data, 

•  lethality  data, 

•  replacement  cost. 


2. 4. 1.1  Missile  Intercept  Range  and  Performance  Envelope 

The  minimum  and  maximum  missile  intercept  ranges  together  with  the 
missile  performance  envelope  define  a  solid  of  revolution  about  an  ori¬ 
gin,  usually  the  position  of  the  launcher,  which  may  be  interpreted  as 
the  set  of  points  in  space  for  which  the  probability  of  a  SAM  fired  from 
the  origin  killing  its  assigned  target  is  roughly  the  design  constant. 
Outside  this  region,  if  a  missile  did  intercept  a  target,  a  target  kill 
would  be  unlikely.  Therefore  the  model  considers  a  missile  for  commit¬ 
ment  to  an  established  enemy  track  only  when  the  projected  point  of  in¬ 
tercept  falls  within  the  missile's  performance  envelope.  Figure  2.4. 1.1-1 
illustrates  a  vertical-half-plane  section  of  an  example  of  a  missile  per¬ 
formance  envelope  with  minimum  and  maximum  missile  intercept  ranges. 
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surveillance  and  tracking  radar  types  (e.g.,  AN/SPS-48,  AN/SPS-49),  the 
surface-to-air  missile  types  and  their  associated  launcher  systems,  and 
the  guidance  channel  constraint  group  types.  The  number  and  physical 
location  on  the  hull  of  each  such  component,  together  with  individual 
component  vulnerability  data,  define  the  surveillance  and  weapons  con¬ 
figuration  of  a  particular  ship  type;  the  ship  type  may  also  be  as¬ 
signed  a  class  name  of  up  to  20  characters  (e.g.,  DDG-2  CLASS  or 
GALVESTON  CLASS).  Sub-routines  used  by  TYPGEN  to  define  surface-to-air 
missile  types,  launcher  types,  radar  types,  ship  component  types,  gui¬ 
dance  channel  constraint  group  types,  and  ship  types  are  MSLGEN,  LCHGEN, 
RDRGEN,  CMPGEN,  GCGEN,  and  SHPGEN  respectively;  the  data  input  formats 
for  each  of  these  routines  are  given  in  Appendix  A  together  with  ampli¬ 
fying  descriptions  of  the  various  parameters  involved. 

The  TDHS  mode  requires  the  addition  of  one  parameter  (on  Card  Type 
TS)  and  a  new  input  card  type.  The  new  parameter  specifies  for  a  given 
ship  type  the  number  of  DET/TRK  operator  positions  available  on  the  ship 
type.  The  new  card  type  (Type  TST)  specifies  the  radar  assignments  for 
the  TRK  SUP  and  for  each  DET/TRK  operator .  Provision  is  also  made  on 
this  card  type  to  assign  individual  operators  to  automatic  offset  mode 
of  operation  for  the  track  updating  process. 


4.4. 1A 

The  radar  survei 1  lance/radar  tracking  version  requires  one  added 
parameter  (on  Card  Type  TS)  and  a  slight  change  in  description  of  two 
parameters  (on  Card  Types  TSR  and  TSG).  The  new  parameter  specifies 
the  time  window  during  which  a  given  target  must  be  detected  at  least 
three  times  by  surveillance  radars  on  the  defined  ship  type  in  order 
to  initiate  a  target  track.  The  change  in  description  of  surveillance 
radar  types  specified  on  Card  Type  TSR  refers  to  the  definition  of 
those  types  now  being  defined  by  Card  Types  TR,  TRB,  and  TRM.  Simi¬ 
larly,  on  Card  Type  TSG  the  tracking  radar  type  refers  to  a  data  set 
defined  by  Card  Type  TR  only. 


4.4.2  Missile  Guidance  Techniques 

The  concept  of  guidance  channel  constraint  groups  (Appendix  G)  has 
been  introduced  into  the  model  so  as  to  afford  a  single  approach  to 
simulating  present-day,  as  well  as  future,  missile  guidance  techniques. 
The  widely  used  dual-simplex  guidance  scheme  uses  two  fully  dedicated 
director-illuminator  tracking  radar  sets  (or  guidance  channels)  with 
each  SAM  launcher.  A  guidance  channel  is  entirely  committed  to  a 
single  engagement  from  initial  target  acquisition  and  missile  launch  to 
intercept  and  kill  evaluation;  thereafter  the  guidance  channel  may  be 
used  to  reengage  the  same  target  or  to  take  under  fire  some  other  tar¬ 
get,  as  the  assignment  doctrine  dictates.  More  efficient  use  is  made 


4-4 


of  the  missile  launcher  by  having  it  supply  missiles  to  two  guidance 
channels  conducting  independent  target  assignments;  this  is  particu¬ 
larly  true  when  the  missile  time  of  flight  to  an  intercept  point  is 
large  compared  with  the  launcher  cycle  (or  reload)  time  delay.  A  dual- 
simplex  system  may  have  no  more  than  two  assignments  (per  launcher)  in 
progress  at  any  given  instant  of  time. 

A  somewhat  different  guidance  scheme  for  more  advanced  missile 
systems  abandons  the  notions  of  fully  dedicated  guidance  channels  and 
exclusive  commitment  of  a  guidance  channel  to  a  target  throughout  the 
course  of  a  missile-and-target  engagement.  With  the  advanced  guidance 
techniques  a  particular  guidance  channel  may  be  serviced  by  any  of 
several  missile  launchers  aboard  the  ship,  and  it  may  divide  its  time 
among  several  missile-and-target  engagements  as  the  data  rate  require¬ 
ments  of  each  dictate.  Physically  the  "guidance  channels"  in  a  multi¬ 
function  phased  array  radar  are  more  difficult  to  visualize  than  the 


4.7  Specification  of  Defense  Units 

Once  a  library  of  ship  types  has  been  established  in  the  data  base, 
specification  of  individual  defense  units  (ships  and  AEW  aircraft)  is 
relatively  easy.  Each  defense  unit  must  be  defined  by  a  single  input 
card  (of  Type  DF)  to  the  Defense  Generator  (DEFGEN)  routine.  Each  such 
DF  card  specifies  the  number,  name,  ship  type,  heading,  and  position  (in 
rectangular  or  cylindrical  coordinates)  of  a  defense  unit.  Also  speci¬ 
fied  is  a  TEWA  group  number  for  defense  units  having  firepower  capabili¬ 
ties;  this  grouping  is  used  within  the  threat-evaluation  procedure  in 
the  determination  of  the  force-wide  engagement  status  of  individual  tar¬ 
gets.  Inputs  to  the  DEFGEN  routine  are  terminated  by  a  Type  DX  card; 
this  card  is  also  used  to  specify  the  location  of  the  Vital  Area  Center 
used  in  force-wide  threat-evaluation  computations. 

Following  the  DEFGEN  inputs  there  may  be  additional,  optional  in¬ 
puts  to  further  refine  the  descri pti ions  of  individual  defense  units. 
These  optional  inputs  fall  into  three  categories;  surveillance-radar 
search-detector  definitions,  launcher  fire-zone  sector  and  salvo  size 
definitions,  and  radar  simulation-model  option  selections  for  individual 
surveillance  radars  and  guidance  channel  groups. 

Any,  all,  or  none  of  the  surveillance  radars  aboard  a  defense  unit 
(as  determined  by  the  corresponding  ship  type  definition)  may  be  assigned 
limited  search  sectors  by  use  of  input  cards  of  Type  SR  to  the  Sector 
Generator(SECGEN)  routine.  Unless  otherwise  specified,  all  surveillance 
radars  are  allowed  full  circle  coverage.  Restricted  search  sectors  are 
defined  by  giving  a  right-hand  boundary  (relative  to  the  ship's  heading 
or  to  north,  as  desired),  and  a  search  sector  width  (of  from  0  to  360 
degrees).  Each  radar  is  then  prohibited  from  making  target  detections 
outside  of  its  assigned  search  sector.  (Individual  surveillance  radars 
may  be  "turned  off"  simply  by  assigning  a  zero-width  search  sector; 
this  is  an  easier  way  to  remove  a  radar  from  a  ship  than  by  going 
through  the  alternative  approach  of  defining  a  different  ship  type.) 

Fire-zone  sectors  for  individual  missiles  may  be  defined  in  a  sim¬ 
ilar  fashion  through  the  use  of  Card  Type  SL.  Full  circle  coverage  is 
again  assumed  unless  otherwise  specified.  Each  launcher  is  prohibited 
from  launching  a  missile  salvo  against  a  target  unless  the  target  lies 
within  its  fire-zone  sector  at  the  time  the  missile  assignment  is  made. 
This  same  card  type  is  also  used  to  specify  the  salvo  size  for  indivi¬ 
dual  launchers  (the  number  of  missiles  to  be  fired  each  time  as  an  as¬ 
signment  is  made).  A  default  value  of  one  (single  missile  salvos)  is 
assumed  unless  otherwise  specified. 

Only  one  such  unit  may  at  present  be  configured  with  surveillance 
radar  sets  in  the  TDHS  version.  Until  the  development  of  the  multiple- 
ship  TDHS  model,  all  defense  units  but  one  must  be  generated  from  ship 
types  having  no  radars  or  defensive  weapon  systems. 

Several  radar  simulation  models  are  available  within  the  program, 
each  representing  a  different  level  of  detail  or  degree  of  sophistica¬ 
tion  in  the  treatment  of  the  radar  detection  process.  Which  radar 
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simulation  option(s)  to  use  in  a  particular  run  depends  on  many  factors, 
including  the  purpose  of  the  run,  the  sensitivity  of  the  outcome  expec¬ 
ted  or  previously  observed  as  a  result  of  the  option(s)  selected,  and 
the  importance  attached  to  minimizing  computer  running-time  costs  (through 
the  selection  of  simple  algorithms).  Each  surveillance  radar  and  each 
guidance  channel  group  (tracking  radar(s))  may  be  independently  assigned 
the  simulation  model  option  desired,  thus  a  number  of  different  radar 
simulation  models  may  be  employed  concurrently  within  a  given  run.  Un¬ 
less  otherwise  specified,  the  simplest  radar  model  is  assumed  (a  deter¬ 
ministic  cookie-cutter  technique);  this  will  yield  the  shortest  possible 
running  time,  but  only  radar  horizon,  scope  limit,  and  horizontal  and 
vertical  coverage  angles  will  be  considered  in  making  detection  deci¬ 
sions— effects  of  ECM  and  target  cross  section  variations  are  ignored. 

In  the  TDHS  version  the  radar  simulation  algorithms  no  longer  pro¬ 
duce  "detected"  targets  but  rather  yield  an  array  of  detectable  video 
coordinates .  A  clustering  routine  in  the  MSP  adjoins  the  video  returns 
from  closely  spaced  targets  according  to  the  radar  resolution  capabili¬ 
ties  and  other  TDHS  tracking  parameters . 

4.7A 

In  the  radar  survei 1  lance/radar  tracking  version  the  radar  detec¬ 
tion  of  targets  is  performed  by  the  SURSEM  submodel  according  to  the 
characterization  of  the  radar  as  defined  by  its  radar  type,  so  radar 
simulation  model  options  as  previously  defined  in  SPEARS  no  longer  apply. 

4.8  Specification  of  Offense  Units 

The  Raid  Generator  (RAIDGEN)  routine  combines  previously  defined 
target  types,  ECM  loading  groups,  and  defense  unit  information  (for  tar¬ 
geting  purposes)  with  flight-path  and  weapon-trajectory  data  to  produce 
individual  offense  units,  both  impacting  and  nonimpacting,  as  diagramed 
in  Fig.  4.5-1. 

Every  offense  unit,  or  target,  is  associated  with  a  piecewise  lin¬ 
ear  Master  Flight  Path  (MFP).  The  MFP  for  a  nonimpacting  target  (e.g., 
launch  vehicle,  standoff  jammer,  strike-command  aircraft,  or  cruise- 
missile-launching  submarine)  may  have  from  two  to  15  nodes  (X.,  Y.,  Z.). 
The  phasing  or  time  of  departure  from  the  first  node  and  the  £peei  aling 
each  flight  path  leg  are  MFP  input  parameters.  Offense  units  flying  in 
formation  may  be  associated  with  a  common  MFP,  with  the  lateral,  axial, 
and  vertical  displacements  of  each  from  the  MFP  being  described  with  the 
specifications  of  each  such  target.  (The  MFP  for  a  nonimpacting  target 
must  be  completely  described  as  part  of  the  run  input  data,  and  there  is 
no  variation  in  such  flight  paths  between  successive  repl  ications. ) 

Any  number  of  nonimpacting  targets  may  share  the  same  basic  MFP, 
with  each  such  target  being  described  by  a  single  input  card  of  Type  RA. 
This  card  specifies  the  target  type  and  ECM  loading  group  (both  previ¬ 
ously  defined  by  inputs  to  the  TYPGEN  routine),  the  displacement  values 
(relative  to  the  most  recently  defined  MFP),  and  the  number  of  parasites 
carried  (if  any). 
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virtue  of  scheduling  an  UPDATE  event  in  the  game  calendar.  The  TRACER 
event  would  thereupon  reschedule  itself,  after  a  suitable  delay-time 
interval  representing  the  period  during  which  the  DET/TRK  operator  is 
occupied  making  the  necessary  console-button-pushing  operations. 

Should  no  video  correlate  with  the  sequenced  track,  then  a  missed- 
report  event  (MISSTK)  is  scheduled  for  the  track  and  the  TRACER  event 
reschedules  itself  after  the  time  required  for  the  radar  to  sweep 
through  the  entire  width  of  the  operator's  zone  of  interest. 

After  a  predetermined  number  of  successive  missed-track  reports,  a 
given  track  becomes  eligible  to  be  dropped  from  the  TDHS  by  the  track 
supervisor.  On  a  time  available  basis  (e.g.,  when  there  are  no  addition¬ 
al  new  detections  to  be  entered)  the  track  supervisor  will  schedule  a 
drop-track  event  (DROPTE)  for  a  track  which  no  longer  has  correlating 
video  available. 

As  the  workload  is  lessened  in  the  TDHS  (by  virtue  of  a  succession 
of  drop-track  actions) ,  it  may  be  appropriate  to  deactivate  one  or  more 
of  the  DET/TRE  operators.  This  is  accomplished  by  application  of  a 
decision  threshold  and,  when  appropriate ,  scheduling  a  SLEEP  event  for 
an  operator;  this  will  have  the  effect  of  removing  the  operator's  next 
scheduled  TRACEER  event  from  the  game  calendar . 


5.3A 


In  the  radar  survei 1  lance/radar  tracking  version  of  the  MSP,  the 
SCAN  event  has  been  rewritten  extensively  to  serve  as  the  link  between 
the  SPEARS  logic  and  the  SURSEM  radar-survei  1  lance  submodel.  A  SCAN 
event  is  now  scheduled  initially  for  each  radar  scan  mode  as  appropri¬ 
ate  by  the  NODE  event.  It  reschedules  itself  according  to  the  periodic 
scan  rate  of  the  radar  scan  mode  it  represents.  The  occurrence  of  a 
SCAN  event  corresponds  to  an  attempt  by  the  specified  radar  scan  mode 
to  detect  any  currently  active  targets  within  its  coverage  volume.  A 
scan  mode  of  a  surveillance  radar  is  considered  "activated"  whenever  a 
SCAN  event  is  scheduled  for  it  in  the  game  event  calendar;  an  ENTER 
event,  signifying  the  entrance  of  a  target  into  the  scan  mode's  cover¬ 
age  volume,  must  occur  for  an  initial  activation  to  take  place. 

The  occurrence  of  a  LEAVE  event  corresponds  to  a  target's  passing 
outside  the  coverage  volume  of  the  scan  mode  of  a  particular  radar.  A 
radar  scan  mode  is  deactivated  when  no  active  targets  are  within  its 
coverage  volume  or  when  the  radar  is  disabled  as  a  result  of  enemy- 
weapon  impact  or  system  failure.  The  deactivation  of  a  radar  scan  mode 
cancels  any  scheduled  SCAN  events  for  that  scan  mode.  Reactivation  of  a 
radar  scan  mode  and  the  scheduling  of  a  corresponding  SCAN  event  follows 
the  occurrence  of  an  appropriate  ENTER  event  or  the  repair  of  the  radar 
set. 
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A  probability  of  detection  for  each  active  target  within  the  cover¬ 
age  volume  of  the  specified  radar  scan  mode  is  calculated  within  the 
SCAN  event,  using  the  SURSEM  submodel.  Monte  Carlo  sampling  is  then 
used  to  determine  if  any  detections  actually  take  place,  and  DETECT 
events  are  scheduled  for  current  game  time  accordingly.  A  primary  dif¬ 
ference  between  this  version  and  the  parent  model  is  that  here  a  radar 
scan  mode  holds  a  target  in  a  detected  status  with  no  effect  on  the 
scheduling  of  subsequent  SCAN  events,  since  update  reports  are  neces¬ 
sary  for  track  establishment  and  maintenance. 

The  occurrence  of  a  DETECT  event  for  a  particular  radar-and-target 
combination  initializes  or  updates  the  track  history  for  that  target  as 
carried  by  the  defense  unit  on  which  the  radar  resides.  A  defense  unit 
establishes  a  target  track  when  any  combination  of  radars  on  the  defense 
unit  detects  a  given  target  three  times  within  a  specified  time  window. 
The  defense  unit  drops  the  track  if  no  update  (detection)  is  recorded 
within  a  given  update  time  period  by  either  the  defense  unit's  own 
radars  or  the  radars  of  any  defense  unit  with  which  it  may  communicate. 

A  PASS  event  is  scheduled  by  the  DETECT  event  to  identify  those 
defense  units  able  to  receive  communication  transmissions  from  the  de¬ 
fense  unit  responsible  for  the  detection.  The  detection  report  is  then 
passed  on  to  each  appropriate  radar  by  means  of  a  PASDET  event.  The 
occurrence  of  a  PASDET  event  for  a  particular  radar-and-target  pair 
triggers  a  check  of  the  track  history  of  the  target  as  carried  by  the 
defense  unit  on  which  the  receiving  radar  resides.  If  a  track  has  al¬ 
ready  been  established,  the  transmitted  detection  will  update  the  track 
history  if  received  within  the  specified  update  time  period.  Otherwise 
it  has  no  effect  on  the  track  history  as  carried  by  the  defense  unit, 
since  a  detection  received  through  a  communication  link  cannot  contri¬ 
bute  toward  track  establishment. 


5.4  Threat-Evaluaton  and  Weapon-Assignment  Events 

There  are  ten  event  types  primarily  associated  with  threat  evalua¬ 
tion  and  weapon  assignment:  TEWA,  ASSIGN,  LAUNCH,  INTCPT,  RELEAS, 
TRNSFR ,  ABORT,  DROP,  COMEIN,  and  OUTGO.  The  TEWA  (threat  evaluation 
and  weapon  assignment)  event  involves  several  large  subroutines  and 
like  event  type  NODE  is  one  of  the  most  complex  event  types  in  the  sim¬ 
ulation  model.  A  TEWA  event  sequence  is  associated  with  each  defense 
unit  having  SAM  firepower  capability.  Scheduling  of  the  initial  TEWA 
event  for  a  defense  unit  is  triggered  by  the  first  detection  made  with 
respect  to  that  defense  unit;  this  TEWA  is  displaced  in  time  from  its 
generating  DETECT  event  by  an  evaluation  reaction  time,  the  value  of 
which  is  specified  on  the  GP  input  data  card.  Thereafter  the  TEWA 
event  for  the  defense  unit  regenerates  itself  according  to  a  time  in¬ 
terval  either  as  specified  on  the  GP  input  data  card  or  as  determined 
by  the  next  earliest  time  of  weapon  availability. 


The  total  number  of  targets  within  SAM  assignment  range  of  any 
given  ship  is  kept  by  incrementing  a  counter  by  one  each  time  a  COMEIN 
event  for  a  particular  ship  occurs  (and  by  decrementing  the  counter  by 
one  each  time  an  OUTGO  event  for  it  occurs).  Whenever  the  in-range 
target  counter,  for  a  particular  defense  unit  is  incremented  from  0  to  1, 
a  TEWA  event  is  scheduled  for  that  ship  unless  there  is  already  one  in 
the  game-event  calendar. 

When  a  TEWA  event  occurs,  the  value  held  in  the  in-range  target 
counter  for  that  defense  unit  is  tested.  If  the  value  is  0,  control 
will  be  returned  immediately  to  the  main  program  without  scheduling  a 
future  TEWA  event  for  the  ship.  Otherwise  a  preliminary  check  is  made 
to  determine  if  the  specified  defense  unit  has  any  weapons  available 
for  possible  assignment  during  the  current  TEWA  interval  (between  cur¬ 
rent  game  time  and  the  latest  time  at  which  the  next  TEWA  event  for 
this  defense  unit  will  occur).  If  no  weapons  are  available,  due  to  en¬ 
gagements  in  process  and/or  to  disablement  of  necessary  weapon  system 
components,  the  event  will  proceed  no  further  but  will  simply  resche¬ 
dule  itself  for  the  earliest  time  at  which  a  weapon  will  become  available. 

If  one  or  more  weapon  systems  are  found  to  be  available  on  the  de¬ 
fense  unit,  then  the  TEWA  routine  will  produce  a  threat-ordered  list  of 
the  targets  currently  held  in  a  detected  status  with  respect  to  the  de¬ 
fense  unit  using  a  threat-ordering  algorithm  patterned  after  the  proce¬ 
dure  used  within  the  Naval  Tactical  Data  System  (NTDS).  Threat  ordering 
is  done  with  respect  to  both  own  ship  and  the  task  force  Vital  Area  Cen¬ 
ter.  Preference  is  given  to  self-defense,  and  then  to  area  defense, 
with  threat-number  ties  being  broken  by  random-number  selection. 

Offense  units  found  to  have  sufficiently  high  threat  numbers  are 
then  considered  for  possible  engagement  by  SAM  weapons.  The  weapon  as¬ 
signment  routine  verifies  availability  of  the  necessary  weapon-system 
components,  performs  a  trial  intercept  calculation,  determines  if  the 
predicted  intercept  point  lies  within  the  performance  envelope  of  the 
missile  type  being  considered,  and  checks  the  guidance  channel  con¬ 
straint  expressions  to  insure  that  they  are  satisfied  throughout  the 
expected  duration  of  the  assignment.  If  more  than  one  SAM  system 
aboard  the  defense  unit  is  capable  of  engaging  the  designated  target, 
preference  will  be  given  in  the  following  order: 

1.  To  the  system  having  the  higher  priority  missile  type,  where 
missile  priority  is  inversely  related  to  maximum  range  cap¬ 
ability  (reflecting  missile  replacement  costs), 

2.  To  the  system  able  to  achieve  the  earliest  assignment  time 
within  the  current  TEWA  interval,  and  finally, 

3.  To  the  system  having  the  greatest  number  of  missiles  remain¬ 
ing  in  its  launcher  magazine. 


Once  a  SAM  system  has  been  selected  for  the  assignment,  an  ASSIGN  event 
will  be  scheduled  in  the  game  calendar,  and  if  weapons  are  still  avail¬ 
able  on  the  defense  unit,  another  target  will  be  considered  for  possible 
engagement.  This  process  will  continue  until  there  are  no  more  engage- 
able  targets  or  no  more  weapons  available  on  the  defense  unit. 

The  ASSIGN  event  indicates  the  pairing  of  a  weapon  and  a  target  as 
determined  in  the  TEWA  process.  The  corresponding  LAUNCH  event  is  then 
scheduled  for  a  time  displaced  from  the  ASSIGN  time  by  the  target  acqui¬ 
sition  delay  of  the  guidance  system  and  the  firing  circuit  activation 
delay  of  the  selected  missile  launcher. 

Occurrence  of  a  LAUNCH  event  corresponds  to  the  firing  of  a  SAM 
from  its  launcher.  The  computed  time  of  flight  to  the  predicted  in¬ 
tercept  point  is  then  used  to  schedule  the  subsequent  INTCPT  event. 

When  the  INTCPT  event  occurs,  a  Monte  Carlo  evaluation  is  made  to 
determine  if  the  missile  succeeded  in  inflicting  lethal  damage  to  its 
assigned  target.  If  so,  a  second  random  sampling  is  made  to  establish 
the  time  required  for  the  target  to  die  (to  become  ineffective  and  eli¬ 
gible  for  removal  from  the  play  of  the  game)  and  a  DIE  event  for  the 
target  is  scheduled  accordingly.  If  the  time  of  death  so  computed  is 
earlier  than  any  previously  held  time  of  death  for  that  target,  then 
the  later  DIE  event  is  removed  from  the  game  calendar.  At  this  point 
the  SAM  system  is  tentatively  given  credit  for  killing  the  target. 

The  INTCPT  event  also  causes  scheduling  of  a  RELEAS  event  for  the 
SAM  system  at  a  later  time,  following  the  kill-evaluation  delay  period 
associated  with  the  weapon  type  used.  Occurrence  of  the  RELEAS  event 
simply  releases  the  weapon  system  from  its  most  recent  engagement,  mak¬ 
ing  it  available  for  a  new  assignment. 

However  not  all  SAM  engagements  can  be  expected  to  go  smoothly 
from  the  ASSIGN  to  the  RELEAS  event.  Some  of  the  possible  causes  for 
disruption  of  the  normal  sequence  of  events  in  the  history  of  a  SAM  en¬ 
gagement  are: 

•  The  target  may  change  its  course  in  such  a  manner  that  inter¬ 
ception  by  the  assigned  missile  is  no  longer  possible  due 
either  to  performance-envelope  restrictions  or  to  violation  of 
the  guidance-channel-constraint  expressions; 

•  The  target  may  be  killed  by  another  missile  system  (target 
preemption) ; 

•  The  target  may  cease  to  exist,  by  reaching  its  final  flight- 
path  node  (this  will  normally  only  happen  for  impacting  tar¬ 
get  types); 
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•  One  or  more  necessary  components  of  the  SAM  system  may  be  dis¬ 
abled  due  to  the  effects  of  an  enemy  weapon  impact. 

Depending  on  the  nature  of  the  disruption,  the  time  at  which  it  occurs 
(relative  to  the  predicted  SAM  engagement  history),  and  the  availability 
of  other  nearby  (indistinguishable)  targets,  the  SAM  engagement  may  be 
dropped,  transferred,  aborted,  or  simply  released. 

A  DROP  event  will  be  scheduled  if  the  assignment  cannot  be  comple¬ 
ted  and  if  the  missile  (salvo)  has  not  been  irrevocably  committed  to 
the  engagement.  Thus,  if  the  launcher  firing  circuit  has  not  yet  been 
activated,  the  assignment  will  be  scratched  with  no  missile  expenditure. 

If  the  SAM  engagement  in  question  has  already  achieved  its  inter¬ 
cept,  then  the  disruption  will  have  little  effect  on  that  assignment 
except  that  the  weapon  system  release  may  be  scheduled  for  a  slightly 
earlier  time. 

A  TRNSFR  event  will  be  scheduled  if  the  launcher  has  been  fired 
(but  target  interception  has  not  yet  occurred),  and  there  is  available 
another  target  to  which  the  assignment  may  be  transferred.  The  rules 
by  which  eligibility  for  transfer  is  decided  are  under  control  of  the 
programmer  so  they  may  be  made  prohibitive  (no  transfers  allowed),  re¬ 
strictive  (transfer  allowed  to  another  target  occupying  the  same  radar 
resolution  cell  as  the  original  target),  or  permissive  (according  to 
virtually  any  other  criteria  desired).  After  a  TRNSFR  event  the  remain¬ 
ing  engagement  events  (e.g.,  INTCPT,  RELEAS)  will  proceed  as  if  the  as¬ 
signment  had  been  originally  made  to  the  new  target  except  that  they 
may  be  rescheduled  to  reflect  a  different  intercept  time. 

If  the  missile  has  been  irrevocably  committed  to  the  engagement 
and  transfer  to  another  target  is  not  possible  (or  allowed),  then  an 
ABORT  event  will  be  scheduled  which  will  terminate  the  engagement  with 
the  unproductive  expenditure  of  the  missile  salvo. 

This  area  of  the  simulation  model  is  currently  deactivated  in  the 
TDHS  version.  To  bring  the  TEH A  functions  into  the  TDHS  SPEARS,  it  will 
be  necessary  to  key  those  functions  to  track-history  data  rather  than  to 
actual  target- position  data  as  is  done  in  the  parent  model. 


5.4A 


The  radar  surveillance/radar  tracking  version  of  SPEARS  employs 
the  threat-evaluation  and  weapon-assignment  events  of  its  parent  model 
with  the  replacement  of  "detection"  by  "established  track".  Scheduling 
of  the  initial  TEWA  event  for  a  defense  unit  is  now  triggered  by  the 
establishment  of  the  first  target  track  by  that  defense  unit.  Within 
TEWA  a  threat-ordered  list  of  all  targets  for  which  the  defense  unit 
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carries  a  current  established  track  is  made  for  potential  weapon  assign¬ 
ment.  An  established  track  is  considered  current  by  TEWA  if  it  has 
been  updated  within  a  specified  update  time  period;  established  tracks 
carried  by  the  defense  unit  found  not  current  by  TEWA  are  dropped. 


5.5  Attrition  of  Offense  Events 

There  are  two  event  types  primarily  related  to  kill,  damage,  and 
disablement  of  offense  units:  DIE  and  VICTIM.  Both  went  types  relate 
to  the  attrition  of  offense  units  through  the  effects  of  defensive  mis¬ 
sile  firepower  and  result  from  the  occurrence  of  an  INTCPT  event. 

Scheduling  of  a  DIE  event  for  a  target  results  from  one  or  more 
successful  intercepts  by  defensive  missile  firepower,  as  previously  dis¬ 
cussed.  If  the  target  has  reached  its  final  flight-path  node  (with  a 
VANISH  or  IMPACT  event)  prior  to  occurrence  of  the  DIE  event,  then  no 
further  action  is  taken  since  the  target  would  have  been  already  re¬ 
moved  from  the  game  play.  Otherwise  the  target  is  tagged  as  being 
"dead"  and  the  SAM  system  responsible  for  the  DIE  event  is  credited 
with  a  target  kill.  The  target  is  then  removed  from  the  game  plan  in 
much  the  same  manner  as  in  the  VANISH  and  IMPACT  events.  In  addition 
any  unlaunched  parasites  or  in-flight  targets  dependent  on  the  killed 
target  for  guidance  signals  will  be  attrited  through  the  use  of  a 
VICTIM  event  type  scheduled  concurrently  with  the  DIE  event  (at  current 
game  time). 

Occurrence  of  a  VICTIM  event  for  an  unlaunched  parasite  involves 
nothing  more  than  tagging  the  target  as  dead  and  crediting  the  respon¬ 
sible  SAM  system  with  an  additional  target  kill.  If  the  VICTIM  event 
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Amplification  of  Card  Type  TR 
(For  the  radar  surveil 1 ance/ radar  tracking  version  only) 

This  version  of  Card  Type  TR  and  Card.  Types  TRB  and  7RM  which  fol¬ 
low  replace  the  original  Card  Types  TR,  TRI,  and  TRF  in  the  radar  sur¬ 
veillance/radar  tracking  version  of  SPEARS. 


Card  Columns 


Description 


1-2 


The  label  TR  indicating  that  this  card  is  a 
radar-type  header. 


6-25  Twenty-character  field  which  may  be  used  to 

assign  a  name  to  this  radar  type. 

26-30  Identification  number  ( NRDR )  for  this  type. 

31-35  Type  of  radar  (1  =  surveillance,  2  =  tracking/ 

fire  control). 


36-40  For  surveillance  radars:  radar  frequency  in 

megahertz. 

For  tracking/fire  control  radars:  target  ac¬ 
quisition  delay  time.  This  delay  represents 
the  mean  time  from  assignment  of  a  fire- 
control  radar  to  a  target  to  the  acquisition 
of  the  target  by  the  radar  (0  to  31  s). 

41-45  For  surveillance  radars:  antenna  pattern 

indicator  (0  =  pencil  beam,  1  =  cosecant 
squared  beam). 

For  tracking/fire  control  radars:  kill  evalua¬ 
tion  delay  time.  This  delay  represents  the 
mean  time  from  intercept  of  a  target  to  the 
assessment  of  the  intercept  (0  to  31  s). 

46-50  Linear  polarization  in  degrees,  from  0  to  90, 

where  0°  =  horizontal  and  90°  =  vertical. 


51-55 


Number  of  radar  scan  modes  (limited  to  15). 


(Fields  46-50  and  51-55  are  ignored  for  tracking/fire-control  radars). 


A-36C 


CABO  I  PUflPOS€ 


Amplification  of  Card  Type  TRB 
(For  the  radar  surveill ance/radar  tracking  version  only) 


Card  Col umns 

Description 

1-3 

The  label  TRB  indicating  that  this  card  con¬ 
tains  seven  basic  radar  parameters  (in  addition 
to  those  on  card  type  TR)  for  surveillance 
radars  only. 

6-15 

Receiver  noise  in  dB, 

16-25 

Horizontal  3-dB  beamwidth  in  degrees. 

26-35 

Vertical  3-dB  beamwidth  in  degrees. 

36-45 

One-way  antenna  gain  in  dB. 

46-55 

One-way  si  delobe  level  in  dB  down. 

56-65 

Receiver  line  loss  in  dB. 

66-75 

Transmitter  line  loss  in  dB. 

A-36E 


Amplification  of  the  First  Card  of  Card  Type  TRM 
(For  the  radar  surveillance/radar  tracking  version  only) 


Card  Columns 
1-3 


6-15 

16-25 

26-35 

36-45 

46-55 

56-65 

66-75 


Description 

The  label  TRM  indicating  that  this  card  con¬ 
tains  surveillance-radar  scan-mode  parameters. 
Three  cards,  each  labeled  TRM,  are  required 
for  each  radar  scan  mode,  which  are  numbered 
by  SPEARS  in  ascending  order  as  they  are  de¬ 
fined,  beginning  with  1. 

Lower  limit  of  elevation-anqle  coverage  in 
degrees. 

Upper  limit  of  elevation-angle  coverage  in 
degrees. 

Peak  power  in  megawatts. 

Pulse  length  in  microseconds. 

Interlook  period  (time  between  scans)  in  seconds. 

Scan  offset  (relative  to  radar  initialization) 
in  seconds. 

Instrumented  range  in  nautical  miles. 


I  P  I  SI  i 


SSI 


OCSCAlPTlON 

OPPOSITION 

Label 

N/A 

(Unused  integer) 

N/A 

Mode-dependent  loss 

RMPAR 

(8.J.NRDR) 

Number  of  pulses  integrated 


Minus  iogjg  (false-alarm 
probabi 1 ity) 


Compressed  pulse  length 


Sea-clutter  improvement 
factor 


Intermediate-frequency 
bandwidth  _ __ 


Mode  dependent  frequency 
increment 


RMPAR 

(9.J.NR0R) 


RMPAR 

(10.J.NR0R) 


RMPAR 

(ll.J.NRDR) 


RMPAR 

(12,J,NRPR) 


RMPAR 

(14.J.NRDR) 


A-  36  H 


Amplification  of  the  Second  Card  of  Card  Type  TRM 
(For  the  radar  surveillance/radar  tracking  version  only) 


Card  Columns 


Descri pti on 


1-3* 


The  label  TRM. 


6-15 


Mode-dependent  loss  in  dB. 


16-25 

26-35 


36-45 

46-55 


Number  of  pulses  integrated. 

Minus  log10(false-alarm  probability).  (For 
example,  if  the  false-alarm  probability  is 
10~6,  it  would  be  entered  as  6.) 

Compressed-pulse  length  in  microseconds. 

Sea-clutter  improvement  factor  in  dB. 


56-65 


66-75 


Intermediate-frequency  bandwidth  in  megahertz. 
(If  0  is  entered,  the  bandwidth  is  set  at  the 
reciprocal  of  the  compressed  pulse  length.) 

Mode-dependent  frequency  incremejJt^rrTmega hertz. 
(A  nonzero  entry  affectj.J^'liorizontal  and 
vertical  beamwidtjL--antr  antenna  gain  for  this 
scan  mode.. 


Survei  1  lam 


Amplification  of  the  Third  Card  of  Card  Type  TRM 
(For  the  radar  surveillance/radar  tracking  version  only) 


Card  Columns 


Description 


1-3 


The  label  TRM. 


6-15 

16-25 


Blanking  time  in  microseconds.  (A  zero  entry 
sets  the  blanking  time  at  the  pulse  length.) 

Rain-clutter  improvement  factor  in  dB. 


A-37 


Amplification  of  Card  Type  TE 

Card  Columns  Description 

1-2  The  label  "TE”  indicates  that  this  is  an  ECM  Loading 

Group  card. 

26-30  The  identification  number  of  the  ECM  Loading  Group  data 

that  follows.  It  may  be  used  as  a  reference  number  when 
generating  targets  (aircraft  and  missiles) . 

31-35  Communications  band  jamming  indicator  where  1  indicates 

that  this  is  a  jamming  group  and  0  (or  blank)  that  it  is 
not. 


36-40 

P-Band 

power 

density 

given 

in 

w/mHz. 

41-45 

L-Band 

power 

density 

given 

in 

w/mHz. 

46-50 

S-Band 

power 

density 

given 

in 

w/mHz. 

51-55 

C-Band 

power 

density 

given 

in 

w/mHz. 

56-60 

X-Band 

powe  c 

density 

given 

in 

w/mHz. 

A -49 


A- 50 


Card  Columns 


1-2 


26-30 


Amplification  of  Card  Type  TC 

Description 

The  label  TC  indicating  that  this  is  a  cross 
section  group-header  card. 

The  identification  number,  NG,  of  the  cross- 
section  group  data  that  follow.  This  value 
may  be  used  as  a  reference  number  in  describ¬ 
ing  a  target  type  on  Card  Type  TT. 


31-35 


Option  number  for  radar  cross-section  data, 
the  available  options  are: 

Option  1:  o(I,M)  =  A(I,1,M), 


Option  2:  a(I,*,M) 


NJ 

[A ( I ,  j  ,M)  *  J'"1], 
j=l 


Option  3:  o(*H,*v,M) 


NI  NJ 


A(i.j.M)  *J"*, 


i=l  j=l 


Option  4*:  a(*,M)  =  A'(1,1,M)  cos  2*  +  A'(2,1,M)  cos  4* 

+A'(3,1,M)  cos  8*  +  A'(4,1,M), 

where 

a  =  the  radar  cross-section  value  computed  for 
the  target  being  considered, 

I  =  the  radar  frequency-band  index, 

M  =  the  cross-section  group  to  which  the  tar¬ 
get  belongs  (=NG), 


•Defined  for  the  radar  surveillance/radar  tracking  version  only. 


Amplification  of  Card  Type  TC  (Concluded) 


Card  Columns 

Descri ption 

A  =  the  cross-section  data  array. 

«  =  the  solid  aspect  angle  of  the  target  with 
respect  to  the  radar  position. 

*u  =  the  horizontal  aspect  angle, 

=  the  vertical  aspect  angle. 

A1  =  coefficients  calculated  as  a  function 
of  the  target  head-on,  broadside,  and 
minimum  radar  cross  sections. 

The  cross-section  values  computed  with 
options  3  and  4  are  independent  of  the 
radar  frequency  band. 

36-40 

Number  of  rows  NI  in  cross-section  data  to  be 
specified  on  Card  Type  TCD  (=3  for  option  4). 

41-45 

Number  of  columns  NJ  in  cross-section  data 
to  be  specified  on  Card  Type  TCD.  If  option 

1  or  4  is  given  on  columns  31-35  of  this  card, 
the  value  of  this  field  is  assumed  to  be  1. 

46-50 

Marcum-Swerling  cross-section  model  number 
(0,1, 2,3,  or  4). 

A- 52 


Amplification  of  Card  Type  TCD 


Repeat  as  many  cards  of  this  type  (up  to  seven  cards)  as  is  neces¬ 
sary  to  describe  the  cross-section  data  array.  Each  card  must  have  the 
letters  TCD  in  columns  1-3. 


If  option  1  or  4  is  selected  on  card  type  TC,  only  one  card  is 
necessary  to  list  the  single  column  of  cross-section  data  for  this 
group.  For  option  4  (defined  for  the  radar  survei 1  lance/radar  tracking 
version  only)  the  entries  represent: 


Card  Columns 


16-25 


Description 


26-35 


O 

Target  head-on  radar  reflective  area  in  m  . 

p 

Target  broadside  radar  reflective  area  in  m 

O 

Target  minimum  radar  reflective  area  in  m  . 


r-  r~  S  DC. 

s°  ESI  i 


DESCRIPTION 

DISPOSITION 

Label 

N/A 

nusea  integer 


>  ■> 

r:  o  — < 

5?  3»  -o 

-^5  0- 


Ship-type  name 

SHPTNM 

(I.NST). 

1=1 .N20BC0 

Ship-type  Index  value 

N/A 

j 

Number  of  scanning  radar  sets  on 

NSHPT 

ship  type  NST 

(NST)C  j 

Number  of  guidance-channel  groups 

NPSHPT. 

on  ship  type  NST 

(NST)  d 

Total  number  of  guidance  channels 

NPSHPT 

on  ship  type  NST 

(NST)  e 

Total  number  of  missile  launchers 

NPSHPT, 

on  ship  type  NST 

(NST)  f 

Number  of  Tracking  Operators  on 

Ship  Type  N$T  (for  TDHS  version 

only)  or  time  window  for  track 

TKESTM(NST)  j 

establishment  (for  radar  surveil¬ 

lance/radar  tracking  version  only 

1 

(Sequence  field) 
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Amplification  of  Card  Type  TS 


Card  Columns 
1-2 

6-25 

26-30 

31-35 

36-40 

41-45 

46-50 

51-55 


Description 

The  label  TS  indicating  that  this  is  a  ship- 
type  header  card. 

Twenty-character  field  which  may  be  used  to 
assign  a  name  to  the  ship  type  being  defined. 

The  identification  number  for  this  ship  type. 

The  number  of  scanning  radar  sets  on  this 
ship  type.  Each  set  will  be  assigned  a  radar 
type  on  Card  Type  TSR. 

The  number  of  guidance  channel  groups  on  this 
ship  type.  Data  for  each  group  are  described 
on  Card  Type  TS6. 

The  total  number  of  guidance  channels  on  this 
ship  type.  Each  guidance  channel  group  has 
associated  with  it  one  or  more  guidance  chan¬ 
nels.  The  sum  of  guidance  channels  over  all 
such  groups  (columns  36-40)  must  agree  with 
the  value  of  this  field. 

The  total  number  of  missile  launchers  on  this 
ship  type.  Each  guidance-channel  group  ser¬ 
vices  one  or  more  launchers.  The  sum  of 
launchers  over  all  such  groups  must  agree  with 
the  value  of  this  field. 

The  number  of  tracking  operators  aboard  this  ship  type 
(for  the  TDHS  version  only),  or  the  time  window 
for  track  establishment  for  radars  on  this 
ship  type,  with  three  detections  being  re¬ 
quired  within  the  time  specified  to  establish 
a  track  (for  the  radar  surveillance/radar 
tracking  version  only). 


A- 57 


A-58 


Amplification  of  Card  Type  TSR 


This  card  is  necessary  if  the  number  of  scanning  radars  specified 
on  Card  Type  TS  is  nonzero.  Columns  1-3  contain  the  letters  TSR.  Each 
scanning  radar  is  assigned  a  radar  type  that  has  previously  been  defined 
by  Card  Types  TR,  TRI,  and  TRF,  (or  by  Card  Types  TR,  TRB,  and  TRM  for 
the  radar  surveillance/radar  tracking  version).  Up  to  seven  scanning 
radar  sets  per  ship  type  are  allowable. 


Amplification  of  Card  Type  TSG 

There  is  one  card  of  this  type  for  each  guidance-channel  group 
(which  means  that  no  cards  are  necessary  if  there  are  zero  groups). 

The  number  of  groups  is  given  on  Card  Type  TS.  Each  group  has  associa¬ 
ted  with  it  one  or  more  guidance  channels  and  services  one  or  more 
launchers.  When  all  TSG  cards  have  been  read  for  a  ship  type,  a  check 
is  made  to  see  that  the  total  number  of  guidance  channels  and  launchers 
over  all  groups  corresponds  to  the  totals  given  on  Card  Type  TS.  If 
agreement  is  not  found,  the  error  indicator  is  turned  on,  a  message  is 
printed,  and  processing  continues. 


Card  Columns 
1-3 


6-10 


11-15 


16-20 

21-25 


Description 

The  label  TSG  indicating  that  this  is  a  wea¬ 
pons  configuration  card  for  a  guidance-channel 
group  IG  belonging  to  the  ship  type  NST  being 
processed. 

Tracking  radar  type  for  guidance-channel  group 
IG  and  ship  type  NST.  This  value  refers  to  a 
data  set  defined  by  Card  Types  TR,  TRI,  and 
TRF  or,  for  the  radar  survei 1 1 ance/radar  track¬ 
ing  version,  by  Card  Type  TR  only. 

The  guidance-channel  constraint-group  type  for 
guidance  channel  group  IG  and  ship  type  NST. 
This  value  refers  to  a  data  set  defined  by 
Card  Types  TG,  TGP,  TGC,  and  TGA.  The  guidance 
channel  constraint-group  type  determines  the 
number  of  guidance  channels  for  group  IG  (Card 
Type  TG). 

The  number  of  launcher  types  NLCHT  serviced  by 
guidance-channel  group  IG. 

The  first  launcher  type  M,  T.  serviced  by 

1,1b 

guidance-channel  group  IG.  This  value  refers 
to  a  data  set  defined  by  Card  Type  TL. 


26-30 


The  number  of  launchers  N.  of  type  M,  TO  ser 

l>lb  1  , 1  b 

viced  by  guidance-channel  group  IG. 


A-61 


Amplification  of  Card  Type  TSG  (Concluded) 


Card  Columns  Description 


31-35 

Same 

as 

card 

columns 

21-25 

but 

for 

M2,1C 

if 

NLCHT  S  2 

36-40 

Same 

as 

card 

columns 

26-30 

but 

for 

N2,IG 

and 

M2,IG  if 

NLCHT 

2. 

41-45 

Same 

as 

card 

columns 

21-25 

but 

for 

M 

3  ,IG 

if 

NLCHT  =  3 

46-50 

Same 

as 

card 

columns 

26-30 

but 

for 

N 

3  ,IG 

and 

M0  if 

3  ,IG 

NLCHT 

— 

3. 

A-62 


Amplification  of  Card  Type  TSC 


One  TSC  card  is  required  for  each  component  associated  with  ship 
type  NST.  Usually  one  such  card  is  defined  for  each  of  the  NR  radar 
systems,  NC  guidance-channel  systems,  and  NL  launcher  systems  as  speci¬ 
fied  on  Card  Type  TS  as  well  as  for  any  other  components  desired  to 
model  the  ship  type.  In  the  radar  survei llance/radar  tracking  version, 
one  TSC  card  must  be  defined  for  each  of  the  surveillance  radar  systems, 
since  the  z  coordinate  of  the  component's  position  as  specified  in  col¬ 
umns  26-30  is  used  as  the  radar  antenna  height.  The  sum  of  components 
taken  over  all  ship  types  in  a  given  replication  may  not  exceed  ICOMAX; 
the  number  associated  with  a  particular  ship  type  may  range  from  zero 
to  ICOMAX.  Within  each  ship  type,  all  type  TSC  cards  must  follow  the 
last  type  TSG  card  and  precede  the  type  TSH  card. 


Card  Columns 

Descri ption 

1-3 

The  label  TSC  indicating  that  this  is  a  compo¬ 
nent  card  for  ship  type  NST. 

6-10 

Component  ID  number,  assigned  by  the  user, 
which  must  be  unique  within  ship  type  NST. 

11-15 

Component  type  number  to  be  associated  with 
this  component,  referring  to  the  data  set 
defined  by  cards  of  type  TP. 

16-20 

x  coordinate  of  the  component's  position  rela¬ 
tive  to  the  local  coordinate  system  of  the 
ship  type  (feet). 

21-25 

y  coordinate  of  the  component's  position  rela¬ 
tive  to  the  local  coordinate  system  of  the 
ship  type  (feet). 

26-30 

z  coordinate  of  the  component's  position  rela¬ 
tive  to  the  local  coordinate  system  of  the 
ship  type  (feet). 

31-35 

Binary  flag  indicating  whether  the  component 
is  exterior  (1)  or  interior  (0)  to  the  ship's 
hul  1 . 
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Amplification  of  Card  Type  TSC  (Continued) 


Card  Columns  Description 

36-40  Scenario  cost  index  indicating  the  component's 

value  to  the  task  force  overall. 

41-45  System  code  indicating  that  this  component  is 

a  radar  (1),  guidance  channel  (2),  launcher 
(3),  or  other  type  of  component  (0  or  blank). 

46-50  System  type  number  giving  the  radar  type  num¬ 

ber,  guidance-channel  type  number,  or  launcher 
type  number,  if  system  code  above  is  1,  2,  or 
3  respectively;  the  field  is  0  or  blank 
otherwi se. 


(This  page  blank) 


caro  I  runrosE 


Amplification  of  Card  Type  EN 


Card  Type  EN  furnishes  the  scenario  environmental  data  for  a  game 
replication.  This  card,  if  present  in  the  input  deck  (see  Card  Type 
EX  for  default  option),  must  follow  Card  Type  CX,  the  communications- 
generator  trailer  card. 


Card  Columns 

Description 

1-2 

The  label  EN  indicating  that  this  is  an  en¬ 
vironmental  data  card. 

6-15 

Wind  speed,  expressed  in  meters  per  second. 

16-25 

Altitude  at  which  the  wind  speed  is  taken, 
expressed  in  meters. 

26-35 

Nominal  reflection  coefficient. 

36-45 

Multipath  indicator  (defined  for  the  radar 
surveillance/radar  tracking  version  only): 

0  *  no  multipath  propagation 


nonzero  =  multipath  propagation. 

46-55  Rainfall  rate,  expressed  in  millimeters/hour 

(defined  for  the  radar  surveillance/radar 
tracking  version  only). 


A-129 


A-130 


I 


Amplification  of  Card  Type  EX 


Card  Type  EX  is  the  trailer  card  for  the  environmental  generator 
and  must  always  appear  in  the  input  deck.  If  no  Card  Type  EN  is 
present,  then  the  default  option  of  zero  for  wind  speed,  altitude, 
reflection  coefficient,  multipath  propagation,  and  rain  is  used. 

Upon  reading  this  card,  execution  control  is  returned  to  the  GENER8 
program. 


Card  Columns  Description 

1-2  The  label  EX  indicating  that  the  environmental 

data  have  been  read. 


f 


A-132 


B-13 


For  the  radar  survei llance/radar  tracking  version  only: 

A.  Packed  Hat  name  IRADPC  .  BPU  name  IBITS2  .  Common  block  name  RADAR 

B.  One  packed  group  per  radar  Set _ _  of  which  there  may  be  63 

C.  Packing  Format: 


First  Field 
Field  Bit.  No  Width 


1  Disabled  (1 )  or  not  (0 


Activated 


Radar  simulation  model  option 


6  Associated  ship  number 


2x6  No.  of  primary  detections  achieved 


31 

H 

Radar  mode  1  activated  (1)  or  not  (0 

32 

H 

Radar  mode  2  activated  (1)  or  not  (0 

1  Radar  mode  n  activated  (1)  or  not  (0) 

1  I  Radar  mode  15  activated  (1)  or  not  (0) 


D.  Bits  per  unit  4b _ .  Total  packed  list  length  todb 

E.  List  dimension  on  machine  with  word  length  of: 

60  bits  48  words;  36  bits  79  words;  bits 

F.  Notes: 


bits. 


words 


1.  Field  b  is  set  to  "1"  by  the  ENTER  event  when  the  initial  scan  for 
this  radar  is  scheduled. 

2.  Fields  a,  b,  and  c  would  normally  be  picked  up  together  as  a  single 
six-bit  field,  with  a  value  greater  than  31  implying  a  disabled  radar 
set. 

B- 14 


A.  Packed  list  name  IRDRPC 


BPU  name  IB1TS3 


Common  block  name 


RADAR 


B.  One  packed  group  per  Radar  Type _  of  which  there  may  be  31 

C.  Packing  Format: 


Field 

First 

Bit  No. 

Field 

Width 

Purpose 

Remarks 

a 

i 

1 

Old  (0)  or  new  (1)  type  data 

b 

2 

1 

Good  (0)  or  bad  (1)  type  data 

Note  ft  1 

c 

3 

3 

Radar  frequency  band  index 

d 

6 

5 

Target  acquisition  delay  for  tracking 
radars 

seconds 

e 

11 

5 

Kill  evaluation  delay  for  tracking  radars 

•• 

f 

16 

5 

Surveillance  radar  scan  rate 

" 

g 

21 

3x5 

Maximum  unambiguous  range 

kft 

D.  Bits  per  unit  _ 35 _ .  Total  packed  list  length  _ 1 ,085 _  bits. 

E.  List  dimension  on  machine  with  word  length  of: 

60  bits  19  words;  36  bits  31  words;  _  bits  _  words 

F.  Notes: 


#1.  These  three  fields  together  constitute  a  single  5  bit  field  during  the 
play  of  the  game  (at  which  time  fields  a  and  b  should  both  be  zero) . 


B-14A 


For  the  radar  surveillance/radar  tracking  version  only: 

A.  Packed  list  name  IRDRPC  .  BPU  name  IBITS3  .  Cotnnon  block  name  RADAR 


B.  One  packed  group  per  radar  type 

C.  Packing  Format: 


of  which  there  may  be 


First 
Bit.  No 

Field 

Width 

Purpose 

1 

1 

Old  (0)  or  new  (1)  type  data 

2 

1 

Good  (0)  or  bad  (1)  type  data 

3 

3 

Type  of  radar  (1)  for  surveillance  and 
(2)  for  tracking/fire  control 

6 

5 

* 

Target  acquisition  delay  for  tracking 
radars 

11 

5 

Kill  evaluation  delay  for  tracking 
radars 

16 

5 

Number  of  radar  scan  modes  (>  0  for  a 
surveillance  radar  and  0  for  a  track¬ 
ing  radar) 

21 

3x5 

Unused 

D.  Bits  per  unit  35  Total  packed  list  length 

E.  List  dimension  on  machine  with  word  length  of: 

60  bits  19  words;  36^  bits  31  words; 

F.  Notes: 


Remarks 


words 


1.  These  three  fields  together  constitute  a  single  five-bit  field  during 
the  play  of  the  game  (at  which  time  fields  a  and  b  should  both  be 
zero) . 


B-14B 


A.  Packed  list  name  NCCCDT  BPU  name  NB7 _ .  Cosmon  block  naote  COMPON 

B.  One  packed  group  per  Component _  of  which  there  may  be  620 

C.  Packing  Format: 


Field 

First 
Bit.  No 

Field 

Width 

Purpose 

Remarks 

mm 

1 

25 

Cumulative  costs 

In  units  of  Q7Q1 

n 

26 

25 

Current  cost  (0) 

In  units  of  Q7Q2 

c 

51 

25 

Cumulative  cost  since  last  repair  event  (d) 

In  units  of  Q7Q3 

D.  Bits  per  unit  75 _ .  Total  packed  list  length  46,500 _ bits. 

E.  List  dimension  on  machine  with  word  length  of: 

60  bits  775  words;  36  bits  1292  words;  bits  words 
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A.  Packed  list  name  NCSGRP  BPU  name  NBITS1  Common  block  name  CSGECM 

B.  One  packed  group  per  CrOSS-Section  group _  of  which  there  may  be  15 _ 

C.  Packing  Format: 


Field 

width  Purpose  Remarks 


First 
Bit.  No 

Field 

Width 

Purpose 

1 

1 

Old  (0)  or  new  (1)  group  data 

2 

1 

Good  (0)  or  bad  (1)  group  data 

3 

3 

Option  number 

6 

3 

Number  of  rows  in  cross-section  data 
array 

9 

3 

Number  of  columns 

12 

3 

Marcum-Swerl ing  cross-section  model 
number 

1 ,  2,  3,  or  4 
Note  1 


0,  1,  2,  3, 
or  4 


D.  Bits  per  unit  14  Total  packed  list  length  210  bite. 

E.  List  dimension  on  machine  with  word  length  of: 

60  bits  4  words;  36  bits  1  words; _  bite  words 

P.  Notes: 

1.  Option  4  is  used  by  the  radar  surveillance/tracking  version  only 
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Sizes:  Full 


,  Reduced  55 


Description 

Points  to  the  location  in  the  array  KTSQ  (below)  of  the 
next  track  to  be  removed  from  the  queue. 

The  number  of  tracks  currently  stored  in  the  array  KTSQ. 

The  dimension  of  the  array  KTSQ. 

An  array,  called  the  drop-track  queue,  which  contains 
tracks  to  be  dropped  by  the  track  supervisor. 

The  time  that  a  track  was  entered  into  the  array  KTSQ. 

An  array  containing  the  minimum  and  maximum  drop- 
track  queue  lengths  along  with  two  parameters  used  to 
compute  the  average  queue  length  during  the  game. 

The  time  at  which  the  minimum  and  maximum  queue 
length,  respectively,  was  attained. 

A  2  x  3  array  where  column  1  contains  the  minimum 
waiting  time  along  with  the  time  of  occurrence,  column  2 
the  maximum  and  its  occurrence  time,  and  row  1,  column  3 , 
the  total  waiting  time. 


Common  block  name 


ENVRON 


S 


F' 


Reduced 


Parameter 

Name 


Dimensions 


Description 


WINDSP 


ALTUDE 

REFCOF 


Wind  speed  (scenario). 

Altitude  at  which  the  wind  speed  was  taken. 
Nominal  reflection  coefficient. 


FMULT 


ultipath  indicator.* 


iRainfall  rate.* 


*  Radar  surveil lance/radar  tracking  version  only 


Parameter 

Name 


Dimensions 


Full  I  Red. 


Description 


Packed  list  of  integer  parameters  for  up  to 
IRMAX  radar  sets. 


The  number  of  bits  required  to  store  the 
information  in  IRADPC  for  one  radar  set. 


Packed  list  of  integer  parameters  for  up  to 
NRTMAX  radar  types. 


The  number  of  bits  required  to  store  the 
information  in  IRDRPC  for  one  radar  type. 


Packed  list  containing  radar  simulation  model 
integer  parameters  for  up  to  NRTOAX  radar  types. 


The  number  of  bits  required  to  store  the  option 
information  in  IRDROP  for  one  radar  type. 


RC 

8,31 

8,31 

Array  of  as  many  as  8  floating  point  parameters 
for  up  to  NRTMAX  radar  types. 

XLMDA 

31 

31 

Normalized  threshold  used  in  probability  of 
detection  computation. 

Notes: 


These  figures  are  based  upon  a  machine  word  length  of  60  bits. 


For  the  radar  surveillance/radar  tracking  version  only: 

Common  block  name  RADAR _  Sizes:  Full  7803*  ,  Reduced  7779* 


Parameter 

Dimensions 

Description 

Name 

Full 

Red. 

IRADPC 

32* 

8* 

Packed  list  of  integer  parameters  for  up  to 

IRMAX  radar  sets. 

IBITS2 

1 

1 

The  number  of  bits  required  to  store  the 
information  in  IRADPC  for  one  radar  set. 

IRDRPC 

19* 

19* 

Packed  list  of  integer  parameters  for  up  to 

NRTMAX  radar  types. 

IBITS3 

1 

1 

The  number  of  bits  required  to  store  the 
information  in  IRDRPC  for  one  radar  type. 

RBPAR 

10,31) 

(10,31) 

Array  of  ten  basic  radar  parameters  for  up 
to  NRTMAX  radar  types. 

RMPAR 

16,15, 

(16,15, 

Array  of  16  radar-mode  parameters  for  up  to 

• 

31) 

31) 

15  modes  on  each  of  at  most  NRTMAX  radar 
types. 

*  These  figures  are  based  on  a  machine  word  length  of  60  bits. 
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Common  block  name 


RADSEC 


Sizes: 


Reduced 


5 


I 


RSET 


Sizes:  Full 


,  Reduced 


10 


! 


Common  block  name 


Parameter 

Dimensions 

Name 

Full 

Red. 

Description 

COSTHT 

1 

The  cosine  of  the  angle *  of  rotation.  Applicable  only  if 
the  reachable  set  is  an  ellipse. 

SINTHT 

1 

The  sine  of  the  angle  of  rotation.  Applicable  only  if  the 
reachable  set  is  an  ellipse. 

BSQ 

1 

Computed  as  1.0  -  E%  where  E  is  the  eccentricity  of  the 
ellipse.  Applicable  only  if  the  reachable  set  is  an  ellipse. 

MRSOPT 

1 

Indicates  the  form  of  the  reachable  set  where  1  means  a 
circle  and  2  an  ellipse. 

RADSQ 

1 

The  square  of  the  radius  limiting  the  size  of  the  reachable 
set. 

SFACTR 

5 

An  array  of  5  scale  factors  which  are  used  to  increase  or 
decrease  the  size  of  the  reachable  set.  The  factors  are  a 
function  of  the  number  of  reports  in  the  track  history. 

Notes: 

*e.g.,  the  angle  between  the  X-axis  and  the  current  flight  path  leg  of 
of  the  target  under  consideration. 


For  the  radar  survei 1 1 ance/ radar  tracking  version  only: 

Common  block  name  SCAN*  Sizes:  Full  7 _ ,  Reduced 


♦This  common  block  serves  as  a  linkage  between  the  SCAN  event  and  the 
target  cross-section  calculation  in  the  SURSEM  submodel. 


Common  block  name  SHIP  Sizes:  Full  566*  .  Reduced  _ i 


Parameter 

Dimensions 

Description 

Name 

Full 

Red. 

ISHPFO 

49* 

11* 

Packed  list  of  integer  parameters  for  up 
to  ISMAX  ships. 

IBITS5 

1 

1 

The  number  of  bits  required  to  store  informa¬ 
tion  in  ISHPFO  for  one  ship. 

KRSHPT 

19* 

19* 

Packed  list  containing  radar  types  for  up  to 
NSTMAX  ship  types. 

KBITS4 

1 

1 

The  number  of  bits  required  to  store  informa¬ 
tion  in  KRSHPT  for  a  maximum  of  seven  radar 
sets  for  a  single  ship  type. 

MNSHPT 

163* 

163* 

Packed  list  of  guidance-channel -group  integer 
parameters  for  up  to  NSTMAX  ship  types. 

MBITS1 

1 

1 

The  number  of  bits  required  to  store  informa¬ 
tion  in  MNSHPT  for  a  maximum  of  seven  guidance- 
channel  groups  for  a  single  ship  type. 

NPSHPT 

20* 

20* 

Packed  list  of  integer  parameters  for  up  to 
NSTMAX  ship  types. 

NBITS4 

1 

1 

The  number  of  bits  required  to  store  informa¬ 
tion  in  NPSHPT  for  one  ship  type. 

NVSHPT 

155* 

155* 

Packed  list  of  component  position  and  vulner¬ 
ability  data  for  up  to  NSTMAX  ship  types. 

NBITS6 

1 

1 

The  number  of  bits  required  to  store  informa¬ 
tion  in  NVSHPT  for  up  to  ten  component  groups 
for  a  single  ship  type. 

SHIPOS 

3,31 

Array  of  position  coordinates  (X,Y,Z)  for  up 
to  ISMAX  ships. 

INRNG 

31 

Array  of  in-range  target  counters  for  up  to 
ISMAX  ships. 

TKESTM 

31 

Array  of  time  windows  for  track  establishment 
by  up  to  NSTMAX  ship  types.  (For  the  radar 
surveillance/tracking  version  only.) 

*  These  figures  are  based  on  a  machine  word  length  of  60  bits. 
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Common  block  name 


TARGET 


*+  *  + 

Sizes:  Full  2113 _ ,  Reduced  497 

_ 2137 1 _ 421$ 


Parameter 

Name 

Dimensions 

Description 

Full 

Red . 

DISP 

3,255 

3,63 

Array  of  target  displacements  (AX, A Y,AZ)  from 
the  associated  master  flight  paths. 

ENDGTO 

1 

1 

The  latest  target  node  time  from  which  parasite 
launches  are  referenced  or,  if  there  are  no 
parasites,  the  latest  node  time  of  any  target. 

JPAR 

1 

■H 

The  total  number  of  parasite  targets  specified 
in  the  RAIDGN  inputs. 

JTGT 

1 

1 

The  total  number  of  targets,  including  para¬ 
sites,  specified  in  the  RAIDGN  inputs. 

JTRGFO 

♦ 

319 

* 

79 

Packed  list  of  integer  parameters  for  up  to 
JTTWAX  targets. 

JBITS3 

i 

i 

i 

The  number  of  bits  required  to  store  infor¬ 
mation  in  JTRGFO  for  a  single  target. 

JWPRF 

* 

8 

* 

8 

Packed  list  of  integer  parameters  for  up  to 
JWPMAX  weapon  profile  descriptions. 

JBITS4 

i 

i 

The  number  of  bits  required  to  store  infor¬ 
mation  in  JWPRF  for  one  weapon  profile. 

NTGPAR 

* 

14 

* 

14 

Packed  list  of  integer  parameters  for  up  to 
NTTMAX  target  types. 

NB1TS5 

i 

i 

The  number  of  bits  required  to  store  infor¬ 
mation  in  NTGPAR  for  one  target  type. 

LPATH 

i 

i 

Dimension+  of  the  PATHS  array. 

PATHS 

1000+ 

200+ 

Array  of  master  flight  path  and  weapon  profile 

data. 

JTFAIL 

23 

Packed  list  of  failure  probabilities  for  up  to  JTMAX  targets. 

JBITS7 

1 

The  number  of  bits  required  to  store  the  failure  probabilities 
in  JTFAIL  for  one  target. 

Notes; 

* 

These  figures  are  based  upon  a  machine  word  length  of  60  bits. 

^The  dimension  of  the  PATHS  array  is  set  arbitrarily;  generation  of 
numerous  and  lengthy  MFPs  and  weapon  profiles  would  necessitate 
increasing  the  dimension  of  this  array, 
t  These  sizes  include  the  storage  unique  to  the  TDHS  version. 
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For  the  radar  surveil lance/ radar  tracking  version  only: 

Common  block  name  TAR  ST _  Sizes:  Full  63  Reduced  63 


Parameter 

Name 


Dimensions 

Full 

Red. 

Description 


ITARST 


63 


63 


STATUS  (active  or  inactive)  of  up  to  JTMAX 
targets  at  current  game  time  SIMTIM 


*  * 

Common  block  name  TECOMM _ .  Sizes:  Full  332  ,  Reduced  84 


Parameter 

Name 

Dimensions 

Description 

Full 

Red. 

ICOMM 

♦ 

17 

♦ 

1 

Packed  list  of  intership-communication -link 
status  values. 

IBITS6 

i 

1 

The  number  of  bits  required  to  store  the 

communications  link  status  data  in  ICOMM  for 
one  ship  (receiver). 

1XMIT 

i 

1 

An  indicator  that  will  override  use  of  the 

ICOMM  list  if  not  equal  to  0.  If  <  0,  then  no 
links  ever  exist;  if  >  0,  then  all  links  always 
exist . 

IMODIF 

* 

17 

♦ 

1 

Packed  list  specifying  which  intership  com¬ 
munications  links  are  allowed  to  be  modified 
by  the  effects  of  enemy  jamming. 

IBITS7 

i 

1 

The  number  of  bits  required  to  store  the 
modification  specifications  in  IMODIF  for  one 
ship  (receiver). 

MODIFY 

i 

1 

An  indicator  that  will  override  use  of  the 
IMODIF  list  if  not  equal  to  0.  If  <  0,  then  no 
links  are  allowed  to  be  modified;  if  >  0,  then 
all  links  are  allowed  to  be  modified. 

COMDLY 

i 

1 

Intership-communications  time  delay  (seconds). 

FDETO 

31 

7 

Time  at  which  the  first  target  detection  takes 
place  by  each  of  ISTOP  ships;  used  to  trigger 
subsequent  TEWA  events. 

TEDLY 

1 

1 

Time  delay  from  first  target  detection  to 
earliest  possible  weapon  assignment  (seconds). 

MTHRT 

255 

63 

Target  threat  number  list,  made  up  and  used 
within  the  TEWA  routine. 

VAC 

2 

2 

Vital  Area  Center  position  coordinates  (X,  Y)  . 

THRES 

4 

4 

Range  squared  threshold  values  used  to 
determine  the  range  parameter  of  a  target's 
threat  nunber. 

Notes: 

* 

These  figures  are  based  upon  a  machine  word  length  of  60  bits. 
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Common  block  name 


TIMCHK 


Si2es:  Full 


60 


Reduced 


60 


Parameter 

Name 

Dimensions 

Description 

Full 

Red. 

TOLER 

60 

60 

The  tolerance,  by  event  type,  within  which  the 
time  of  a  scheduled  event  must  agree  with  a 
designated  time  In  order  for  the  former  to  be 
canceled  from  the  calendar  by  routine  CANCEL. 
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Common  block  name 


TIMES 


Sizes:  Full 


515  ,  Reduced 


131 


Parameter 


Dimensions 


255  63 


Description 


The  time  delay  between  the  decision  to  abort 
a  launched  missile  and  the  occurrence  of  the 
abort. 


The  assignment  time  of  a  guidance  channel's 
currently  held  assignment.  _ 


End  of  play  time  computed  by  the  simulation 
program.  If  there  are  no  parasites,  ENDTIM  is 
equal  to  ENDGTM  (see  common  block  TARGET) .  If 
there  are  parasites,  when  time  ENDGTM  is 
reached  a  check  is  made  to  see  if  there  are 
active  parasites  remaining.  If  there  are, 
ENDTIM  is  equal  to  the  latest  impact  time;  if 
there  are  not,  ENDTIM  is  ENDGTM.  _ 


End  of  play  time  specified  on  the  game 
parameter  card.  _ 


The  release  time  of  a  guidance  channel  from 
its  currently  held  assignment.  _ 


The  time  between  successive  TEWA  events  for 
a  ship  group.  _ _ 


Variable  representing  a  time  of  positive 


infinity  (arbitrarily  assigned  a  value  of  10 
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For  the  radar  surveillance/ radar  tracking  version  only: 

Common  block  name  TRACK _ .  Sizes:  Full  1323  ,  Reduced  1323 


Parameter 

Dimensions 

Name 

Full 

Red. 

Description 

ITRACK 

(63,71 

(63,7) 

Status  of  tracks  for  up  to  JTMAX  targets  carried 
by  up  to  ISMAX  ships. 

TRKTIM 

(63,7,2) 

(63,7,2) 

Initial  and  most  recent  detection/update  times 
for  up  to  JTMAX  target  tracks  carried  by  up  to 
ISMAX  ships. 

